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ABSTRACT 


Traditionally  computer  descriptive  languages  have-  been  designed  primarily  for 
human  communication  and/or  simulation.  Due  to  this  r, arrow  range  of  applications  the 
existing  languages  have  taken  on  a strong  degree  of  similarity.  In  this  paper  we 
present  some  applications  in  the  realm  of  automatic  design  of  bo.h  hardware  end 
software  where  a computer  description  language  could  serve  as  the  mforma 
exchange  media  between  the  user  and  the  design  automation  system.  The  paper 
discusses  an  environment  for  research  on  the  applications  of  computer  oescr.ptive 
languages,  emphasizing  the  multiplicity  of  of  users  and  tasks  that  may  coexist  an  any 
point  in  time.  Some  properties  needed  in  a computer  descriptive  language  are 
presented.  A structured  programming  approach  to  hardware  design  is  presented  by 

example. 


# This  paper  describes  a current  research  effort  at  Carnegie -Mellon  University.  The 
'utnors  wish  to  make  clear  the  active  role  being  played  in  this  research  project  by 
many  other  members  of  the  CMU  community:  Samuel  Fuller,  Paul  Hilfmger,  David 
Jefferson,  Karla  Martin,  Joseph  Newcomer,  Allen  Newell,  John  Oak.ey,  Mary  .haw, 
Richard  Swan,  and  William  Wulf. 

This  wot.  is  supported  in  part  by  the  Advanced  Research  Projects  Agency  (ARPA)  of 
the  Department  of  Defense,  under  contract  F44C20-73-C-0074,  monitored  by Jhe  ir 
Force  Office  of  Scientific  Research  and  by  the  National  Science  Foundation  under  grant 

GJ  32758X. 
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INTRODUCTION 


Traditionally  computer  descriptive  languages  have  been  designed  primarily  for 
human  communication  and/or  simulation  [tnu,  1965;  Dell,  1971].  Due  to  this  narrow 
range  of  applications  the  ex, sting  languages  have  taken  on  a strong  degree  of  similarity 
[Barbacci,  1973a].  There  are  other  applications  in  the  realm  of  automatic  design  of 
bo*h  hardware  and  software  where  a computer  description  language  could  serve  as  the 
information  exchange  media  between  tne  user  and  the  design  automation  system.  By 
examining  these  applications  the  information  requirements  can  be  determined  and  from 
these  a anguage  that  serves  for  several  (but  still  not  necessarily  for  all)  applications 
can  be  designed. 

This  paper  descrioes  some  preliminary  resul.s  of  a research  group  at 
Carnegie —Mellon  University.  We  present  a case  for  machine —relative  software  and 
other  re'ated  areas  of  research.  A brief  discussion  of  the  domain  of  tasks  we  are 
considering  is  followed  by  a more  detailed  description  of  the  requirements  for  two  of 
them,  namely  the  design  of  machine  relative  compiler -compilers  and  the  design  of 
modular  hardware  systems.  We  present  an  overview  of  an  environment  for  research  in 
these  multiple  applications.  The  key  word  here  is  "multiple".  We  visualize  a system 
that  will  support  multiple,  concurrent  users,  investigating  different  aspects  of  the 
problem  domain,  implementing  subsystems  in  different  programming  languages  which 
manipulate  machine  descriptions  given  in  different  computer  description  languages.  One 
ot  the  key  issues  is  the  specification  of  adequate  computer  description  'anguages.  We 
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discuss  some  properties  desired  in  such  notations  and,  finally  an  example  in  a 
structured  programming  approach  to  top-down  computer  design  is  used  to  present 
some  of  our  ideas  in  just  one  of  the  several  areas  of  our  research  interests,  albeit  a 
crutial  one. 


MACHINE  RELATIVE  SOFTWARE 


There  is  a continual  stream  of  new  machines  spurred  by  the  advent  of 
minicomputers  and  microprocessors.  Each  macmne  has  a different  Instruction  Set 
Processor  (ISP)  [Bell,  1971].  The  emergence  of  microcoded  systems  with  the  option 
of  user  defined  instructions  has  increased  this  flow  of  ISPs.  Each  new  system  requires 
supporting  software  and  the  amount  of  software  grows  for  any  individual  system  as 
user  requirements  grow. 

There  are  a number  of  directions  in  which  to  seek  a solution  to  ease  the  burden 
of  software  development.  Standardization  of  software  packages  written  in  high  level 
languages  such  as  Algol,  FORTRAN,  and  COBOL  is  one  approach.  It  reduces  the  amount 
of  software  needed  for  each  new  machine.  A second  direction  is  in  terms  of  better 
software  production  systems.  This  may  be  sought  either  in  teems  jf  implementation 
systems  (high  level  languages  specifically  designed  to  aid  implementation)  or  in  terms 
of  better  software  methodologies  (e.g.,  structured  programming).  Another  direction, 
which  we  will  consider  in  detail,  is  to  relativize  the  production  of  software  to  the 


description  of  the  machine. 
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The  central  ingredient  of  this  latter  approach  is  the  description  of  computer 
systems  in  a symbolic  form,  such  that  a range  of  problems  can  be  solved  by 
manipulation  of  these  descriptions.  We  stress  the  need  for  diversity  in  the  problem 
domain  if  we  are  really  to  understand  how  to  operate  relative  to  computer  descriptions. 

The  next  section  will  illustrate  some  points  in  the  problem  domain. 


APPLICATIONS  OF  COMPUTER  DESCRIPTIONS 


To  be  ciear  about  the  multipurpose  character  of  a computer  description,  let  us 
list  several  Kinds  of  problems  that  one  might  want  to  solve,  each  of  which  requ’res  an 
abstract'  description  of  a computer. 


1)  Compiler-Compiler.-  A system  that  takes  as  input  a description  of  a 
langU3ge  ,-nd  a description  of  a machine  and  outputs  \ compiler  for  t ha i 
computer.  Given  the  state  of  the  art,  the  language  would  probably  be 
restreted  to  be  Algol -like.  [Miller,  1971]  is  an  early  attempt  at  a solution  to 
this  problem. 

2)  Verification  of  / /0  programs.-  Given  an  I/O  program,  such  as  a device 
hander,  and  a description  of  both  the  computer  and  the  hardware  device 
controller,  verify  that  the  program  works.  This  problem  has  some  special 
features  that  set  it  apart  from  the  general  program  verification  problem, 
brides  its  importance  as  an  applied  task:  (a)  its  strong  dependence  on  the 
description  of  computer  systems  in  classic  form  (i.e.,  at  the  Register  Transfer 
level)  rather  than  in  some  abstract  semantics,  (b)  the  programs  themselves 
may  noi  be  very  complex  in  terms  of  their  algorithms;  rather  the  complexity  of 
the  task  arises  from  the  openness  of  the  environmental  states  that  have  to  cope 
with  (liming,  concurrency,  etc.) 

3)  Programming  of  Microcoded  Special  Computers.-  The  ability  to  create 
soecialized  computers  to  perform  particular  narrow  classes  of  algorithms 
economically  opens  a world  of  device  dependent,  one-time  programming  tasks 
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tnat  poses  an  immense  problem.  These  systems  attempt  to  optimize 
performance;  their  organization  cannot  be  dtctated  by  consi  era  ions 
programming  ease.  Them  programming  will  become  dift.cu.t  in  the  extreme 
especia  ly  when  no  opportunity  will  exists  for  the  growth  of  programming 
Know-how.  This  suggests  that  what  the  human  will  do  is  to  program  re  a ive 
to  a machine  descr.ption  that  he  has  barely  assimilated.  Hence  ,t  ,s  reasonable 
to  construct  programming  systems  that  operate  relative  to  machine  descriptions 

of  a class  of  machines. 

4)  Design  of  Modular  System.-  Given  a desired  machine  described  in  terms 
of  some  specification  language,  and  given  a space  of  machines  oef  nec  y 
class  of  Register  Transfer  [Bell,  1971]  level  modules,  design  a maclu  e 
according  to  various  constraints  and  criterion  functions.  This  is  a classic  desig 
situation  which  is  worth  studying,  both  in  terms  of  understanding  ^e  nature  0 
design  and  in  terms  of  automating  computer  design.  The  ‘eas.bi  i V 
approach  has  been  demonstrated  by  the  EXPL  system  [Barbacci,  1973b]. 

5)  Design  to  specification.-  Given  a functional  specification  for  a computer 
and  a space  of  computer  systems  defined  by  a computer  description  .angua„  , 
design  a computer  that  performs  to  the  specification.  This  is  another  form  o 
the  classical  design  tasK.  It  differs  from  (4)  above.  A typical  task  here  is: 
g !en  some  general  functions,  create  an  ISP  for  a computer.  A typical  tas  m 
(4)  is:  given  an  ISP,  design  it  in  terms  of  Register  Transfer  leve  modoles. 
Formally  they  may  seem  identical,  but  the  design  spaces  look  quite  dmerent. 

6)  Design  Verification.-  Given  a specification  for  a computer  and  a description 
of  that  computer  in  the  language,  verify  that  the  computer  sa hsf  es  he 
specification.  We  can  also  include  here  the  automatic  generauon  of  testn  0 
diagnostic  programs. 

7)  Manual  generation.-  Given  a computer  defined  in  the  language,  create  lr,e 
documentation  for  the  computer.  This  task  is  quite  different  Torn  the  one 
above,  but  also  involves  understanding  and  manipulating  a computer  description. 


The  applications  listed  above  place  a variety  of  demands  on  the  computer 
descriptive  language  and  it  is  hardly  clear  whether  a single  language  can  cover  the 
entire  spectrum.  The  next  sub -sections  give  some  examples  of  the  requirements  for 
two  rather  different  tasks  and  an  outline  of  a possible  system  to  meet  the  variety  of 


requirements. 


Some  Aspects  of  the  Symbolic  Manipulation  o 

of  Computer  Descriptions 

Machine  Relative  Compiler-Compilers.—  By  "machine  relative"  we  imply  an  extension  to 
the  traditional  definition  of  a compiler -compiler,  in  which  a specific  target  machine  is 
assumed.  Due  to  this  limitation,  compiler -compilers  have  solved  only  part  of  the 
automatic  programming  problem  and  as  a result  they  have  not  been  very  succesful.  A 
better  approach  has  been  to  produce  a compiler  that  generates  pseudo -machine  code. 
For  each  new  ISP  the  programmer  simply  provides  the  equivalent  of  the 
pseudo -machine  instructions  in  terms  of  macros  written  in  the  target  machine  language 
[Feldman,  196C].  White  runnabie  programs  are  produced  by  tms  tecnmque  they  are 
poor  in  terms  of  size  and  run  ti me  efficiency.  There  are  several  reasons  for  this  lack 
of  efficiency:  built -in  preconceptions  about  existing  instructions,  the  introduction  of  an 
extra  level  of  abstraction  that  must  be  h«rid  translated,  the  lacK  of  consideration  for 
specific  machine  features  that  can  do  certain  things  more  efficiently  that  others,  etc. 

Hence  we  are  primarily  interested  in  generating  an  optimizing  compiler.  In  order 
to  generate  machine  code  that  will  rival  that  of  a good  programmer,  a 
compiler  -compiler  must  extract  the  idiosyncrasies  of  the  machine.  For  example,  one 
way  to  add  four  to  a register  in  the  PDP-11  [DEC,  *973]  is  to  use  the  instruction 
"ADD  uA,Rl".  This  requires  two  16-bit  words,  one  for  the  instruction  and  one  for  the 
immediate  operand  A.  however,  the  autoincrement  addressing  mode  adds  two  to  a 
designated  register  after  using  its  contents  as  the  address  of  an  operand.  Thus  an 
instruction  that  effectively  is  a No -Operation  code  and  uses  the  autoincrement  mode  on 
the  register  for  both  source  and  destination  operands  can  achieve  the  effect  of  adding 
A to  the  register.  Thus  "CMP  (R1 ) + ,(R1 ) +'*  will  add  A to  R1  and  requires  only  one 
16 -Pit  word.  Note  that  the  compare  instruction  is  not  a true  NOOP  since  it  will  set  the 
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condition  code  registers  according  to  the  result  of  the  comparison.  The  compiler  has  to 
insure  tnat  this  side  effect  is  not  critical.  One  such  critical  case  would  be  if  the 
contents  of  R1  is  used  as  a loop  index  and  a loop  exiting  branch  was  to  follow  the 
addition.  Note  further  that  knowledge  of  the  relative  speed  of  instructions  and 
addressing  modes  may  be  necessary  to  make  a cnoice  on  the  basis  of  speed. 

Some  of  tne  information  that  needs  to  be  extracted  from  the  machine  description 
is:  the  data  types  (address,  integers,  floating  point,  etc),  operations  on  the  data  types 
(add,  subtract,  multiply,  etc),  location  of  data  types  (memory,  register,  etc),  and 
instruction  side  effects  (condition  codes,  use  of  hidden  operands,  etc).  Instruction  side 
effects  are  particularly  important.  The  following  PDP-11  code  sequence  is  a good 
example : 


SUB  A,B 
TST  B 
BLE  LABEL 

where  the  TST  instruction  serves  only  to  clear  the  overflow  condition  code.  If  the 
Branch  on  Less  or  Equal  instruction  (which  is  conditioned  by  the  overflow  condition 
code)  is  replaced  by  a Branch  on  Equal  instruction  (not  dependant  on  the  overflow 
condition)  then  the  test  instruction  is  superfluous  and  can  be  deleted. 

One  of  the  desired  goals  of  a compiler  is  to  produce  the  minimum  cost  code 
sequence  which  evaluates  a given  program.  It  is  therefore  necessary  to  explore  all 
possible  sequences  that  represent  the  evaluation  and  are  semantically  equivalent  and 
eliminate  those  that  exceed  the  least -cost  criteria.  This  semantic  equivalence  is 
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related  ?o  the  effect  on  the  global  program  state  in  the  context  in  which  the  sequence  is 
to  oe  executed.  It  is  therefore  necessary  to  express  the  global  program  state 
conditions  under  which  a code  sequence  can  be  applied,  as  wen  as  the  resulting 
transfo  mations  on  the  state.  This  synergistic  effect  of  machine  language  instructions 
nas  not  been  considered  part  of  the  reaim  of  traditional  computer  description  languages. 

The  cost  of  compile  time  generation  of  cases  must  be  weighted  against  the 
advantages  of  finding  the  best  code  sequences.  An  intermediate  solution  is  the 
exhaustive  generation  of  templates  to  guide  the  code  generation,  as  in  traditional 
compilers.  This  once -only  exhaustive  generation  process  is  more  likely  to  find  all  the 
obscure  cases  and  discover  unspected  semantic  equivalences  than  hand  — des'gneri 
templates  [Newcomer,  1974]. 

Modular  Design.-  Now  cons  der  a modular  design  program  that  produces  a finished 
machine  design  in  terms  of  a preaescribed  module  s>i  ’.  A modular  implementation  of  a 
system  can  usually  be  divided  into  a data  part  and  a control  part  that  directs  the  actions 
of  the  data  part  [Ben,  972].  The  data  types  and  their  operations  can  be  implemented 
via  templates  of  modules.  Again,  as  in  the  case  of  the  compi  er -compiler,  synergistic 
effects  must  be  discovered  in  order  to  produce  the  most  efficient  network  of  modules 
for  a given  machine  description.  This  implies  certain  commonality  of  information 
required  by  this  two  applications.  However,  there  are  many  details  of  a module  set 
that  the  compiler -compiler  does  not  need  to  know.  Assume  that  the  modules  are 
commercially  available  semiconductor  chips  and  that  the  output  from  the  design  program 
is  a printed  circuit  board  layout.  Knowledge  of  chip  orientation,  power  requirements, 


t 


t 

1 

I 


< 


t 





Some  Aspects  of  the  Symbolic  Manipulation 
of  Computer  Descriptions 


8 


l 


and  chip  spacing  is  needed  by  the  design  automation  system  to  produce  a wiring  list. 

Hence  there  is  information  contained  in  the  computer  description  that  is  required 
by  two  or  more  applications  while  some  other  information  is  particular  to  a single 
app  cation. 


/J  research  environment  for  the  symbolic  manipulation  of  machine  descriptions.-  The 
si rr  ar  requirements  among  the  several  applications  of  computer  description  languages 
suggest  a researen  environment  centered  around  a data  base  in  which  machine 

i 

* descriptions  and  manipulation  programs  are  maintained,  as  depicted  in  Figure  1. 
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Figure  1.  The  environment 


The  user  inputs  information  into  the  data  base  via  one  or  more  computer 
description  languages.  The  application  programs  manipulate  the  global  data  base  to 
extract  information  in  the  format  des.red  by  the  application. 


< 


The  data  base  and  its  manipulation  programs  must  be  able  to  support  many 
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different  notations  and  areas  of  application.  This  can  be  expressed  by  the  following 
set  of  required  features: 


1 ) Must  hold  all  computer  descriptions  for  the  different  applications. 

Must  De  reasonably  independent  of  any  particular  programming  language. 
This  is  necessary  to  aliow  researchers  the  flexibility  to  implement  anplication 
programs  (i.e.  computer  description  manipulators)  in  a programmin',  language 
of  iheir  choice  (e.g.,  FORTRAN,  Algol,  APl,  LISP,  BLISS,  etc.) 

3)  Must  be  independent  of  any  particular  computer  description  language.  The 
reason  is  that  the  computei  descriptive  language  used  to  create  elements  of  the 
date  base  is  a moving  target.  It  is  also  the  case  that  so  ne  notations  may  be 
more  suitable  tnan  otners  for  specific  parts  of  a machine  description.  This 
implies  an  evolutionary  process,  during  which  many  different  notations  can  be  in 
use  simultaneously. 

4)  Must  be  interactive  to  allow  casual  and  non-casual  use.  This  requires  a 
set  of  facilities  for  interaction  in  at  least  one  language. 

5)  Must  allow  incremental  use  by  many  simultaneous  users.  By  incremental 
use  ' 'e  mean  the  ability  to  carry  a design  through  stages  of  comple.eness 
during  which  different  users  add  application  dependant  details  to  a computer 
description.  This  is  needed  for  experimentation. 


The  features  outlined  above  present  a set  of  requirements  that  may  be 
conflicting.  One  of  the  reasons  for  this  generality,  not  addressed  in  previous 
applications,  is  that  the  objects  we  want  to  manipulate,  namely  computer  descriptions 
represent  a tremendously  large  domain.  We  are  talking  not  only  about  haroware 
(Logic,  Register  Transfer,  and  PMS  levels  (Bell,  1971])  but  also  aoout  algorithms 
(Instruction  Set  Processors  and  programs).  It  is  also  the  case  that  we  are  trying  to 
appiy  a coherent  methodology  to  hardware  desi  jn(  a domain  characterized  oy  rather 
abrupt  transitions  between  its  descriptive  levels  (more  so  than  among  software  levels). 

Ideally  we  would  like  to  converge  on  a single  computer  descriptive  language  so 
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that  people  in  the  environment  can  interact  more  easily  among  themselves.  On  the 
other  hand,  we  recognize  tne  fact  that  rota*  ins  go  through  evolutions  and  the  research 
environment  must  be  open  along  this  dimension.  An.,  kind  of  tight  association  between 
a computer  description  language  and  the  data  base  will  reduce  tne  latter's  usefulness. 

The  next  section  describes  some  thoughts  about  the  requirements  of  a computer 
descriptive  language  At  this  point  in  time,  however,  we  hold  no  commitments  to  any 
particular  existing  language  or  combination  of  languages.  This  allows  us  the  freedom  to 
speculate  and  experiment  with  several,  perhaps  conflicting  ideas.  Therefore,  our  use 
of  a particular  syntax  in  the  example  given  as  a structured  Drogramming  approach 
should  not  be  construed  as  a language  definition. 


REQUIREMENTS  OF  A COMPUTER  DESCRIPTIVE  LANGUAGE 


One  of  the  problems  with  existing  hardware  descriptive  languages  is  that  they 
tend  to  bind  the  user  to  a view  of  the  world  that  is  rigid  and  difficult  to  modify.  We 
feel  that  the  semantics  of  the  language  should  be  under  control  of  the  designer.  The 
foilr wing  are  a desireable,  but  by  no  means  exhaustive,  set  of  properties  for  the 
language : 


1)  Neutrality.—  The  language  should  not  make  any  assumptions  about  the 
physical  implementation.  The  control  primitives  available  in  the  language 
determine  the  control  structures  that  are  easy  to  describe.  If  the  language 
control  primitives  -e  too  rigid  they  w,ll  limit  the  implementation  alternatives. 
For  instance,  CASSA,  DRE  [Anceau,  1969]  uses  state  registers  as  primitives. 
Systems  which  do  not  decode  values  from  centralized  state  registers  are 
therefore  difficult  to  describe. 
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2)  i'idclity.-  The  description  should  make  the  intentions  of  the  designers 
transpare.it  to  the  users.  This  is  somewhat  in  conflict  with  the  neutrality 
property. 

2.1)  Timing  Fidelity.-  Existing  languages  such  as  ISP  [Bell,  1971] 
describe  algorithms  with  no  reference  to  timing.  Thus  it  becomes  difficult 
*0  express  the  behavior  of  low  level  components.  Another  example  is  the 
description  o'  cooperating  parallel  processes,  such  as  interrupt  systems, 
where  timing  is  critical. 

2.2)  Structural  Fidelity.-  Data  paths  can  be  interred  from  the  descripnon 

but  these  may  be  a maximal  set  and  may  not  reflect  the  actual  structure  of 
the  machine.  At  some  level  of  description  the  transfer  operation,  usually 
denoted  by  means  "by  whatever  path  available".  For  a more  detailed 

description  the  correspond  one-to-one  with  physical  data  paths. 

The  same  remarks  can  be  applied  to  the  specification  of  the  functional  units 
in  the  system.  The  presence  of  a " + " operator  in  a register  transfer 
expression  does  not  indicate  which  of  possibly  many  functional  units  is  to 
carry  out  the  operation. 


3)  Hierarchy.-  Frequently  systems  design  is  conducted  in  a top  dovn  manner. 
The  various  portions  of  the  system  are  first  described  at  a high  level.  Then  the 
designer  specifies  one  subsystem  in  more  detail,  .'.un  another,  and  so  forth. 
At  any  given  time  a systems  design  might  consist  o'  some  subsystems  designed 
down  to  the  gate  ievel,  some  less  detailed  designed  at  the  register  transfer 
level,  and  some  merely  described  as  algorithms.  The  coexistance  of  multiple 
levels  of  description  is  difficult  to  attain  in  existing  design  languages  where  top 
down  refinements,  if  possible  at  all,  are  performed  on  a global  basis  by  ad-hoc 
manual  procedures.  The  addition  of  a clock  at  some  levei  of  detail,  for 
instance,  requires  the  rewriting  of  the  entire  description.  Any  validation  that 
has  been  performed  on  part  of  the  description  would  have  to  be  redone. 


The  final  section  introduces,  via  examples,  some  thoughts  on  new  mechanisms 
for  a computer  descriptive  language  that  attempt  to  satisfy  some  of  the  above 


requirements. 
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A STRUCTURED  PROGRAMMING  APPROACH  TO  4 

/ 

COMPUTER  DESCRIPTION  PROBLEM 

/ 

I 

I 

This  section  presents,  via  examples,  some  aspects  of  the  use  of  new  computer 

description  concepts.  We  will  present  our  ideas  as  an  exerc/ise  in  top  down  design. 

I 

! he  objective  is  to  design  a PDP-8  like  minicomputer,  starting  from  a high  level 
description  and  carrying  the  design  down  to  a level  in  which  he  specific  implementation 
of  the  machine  is  described.  We  will  make  use  of  some  structured  programming 

concepts  that  allow  us  to  defire  entities  of  the  machine  (e.g.,  memories,  registers, 

j 

functional  units)  independently  from  the  use  of  the  entities  in  the  description,  These 
concepts  will  be  added  to  the  descriptive  language  !SP  [Bell,  1971],  The  choice  of  ISP 
as  a framework  is  based  on  the  authors  familiarity  w th  the  notation  and  not,  on  a 
commitment  to  addopt  an  ISP  derived  notation  as  the  only  vehicle  for  our  research.  Our 
concern  for  allowing  evolutionary  notations  is  a^o  reflected  in  certain  liberties  we  have 
taken  with  respect  to  the  syntax  of  the  language  as  published  in  [Bell,  1971]. 

The  concept  of  form  [Wulf,  1974]  allows  us  to  define  the  data  types  available  in 
the  language  by  specifying  not  only  the  representation  of  the  typed  objects  but  also 
the  operations  *hat  can  be  performed  on  these  objects.  A typical  form  declaration 
consists  of  a header  and  a body.  The  form  header  specifies  the  form  name  and  the 
formal  parameters  used  inside  the  form  body.  The  form  body  consists  of  a declaration 
part,  in  which  variables  to  be  used  in  the  form  functions  can  be  defined,  and  a set  of 
functions  and  operations  describing  the  operations  that  can  be  performed  on  variables 
declared  as  instances  of  1. »e  form. 
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For  instance,  we  can  define  a to  "memory"  that  describes  a particular 
hardware  component.  At  some  early  point  in  the  design  process  a memory  can  be 
considered  as  a vector  of  integers,  thus  avoiding  the  specification  of  things  like  word 
length,  number  representation,  addressing,  etc.  The  following  example  is  an  instance 
of  such  high  level  memory  definition*.  Two  functions  (operations),  "read”  and  "write" 
are  defined  as  accesses  to  a vector  of  integers: 


form  memory  (integer  si2e)  = 

{dnciiOi  m = integer  vector(size); 
fiinSLiifla  read  (integer  addr)  = return  m 
function  write  (integer  addr.vai)  = m[addr]  ♦- val ; 
export  read,  write  } 


The  Export  statement  is  used  to  indicate  the  form  entities  (variables  and 
operations)  that  are  accessible  to  the  rest  of  the  program.  Thus  we  can  restrict  the 
access  to  certain  elements  of  the  to  by  not  exporting  them.  The  read  and  write 
functions  are  evoked  automatically,  depending  on  the  context  in  wich  the  memories 
appear,  i.e.,  as  a source  (read)  or  a destination  (write)  in  a statement. 

Similarly,  we  can  define  a form  "register"  that  behaves  like  an  integer: 


* In  order  to  keep  the  examples  within  a reasonable  size,  we  are  appealing  to  the 
intuition  of  the  readers  to  supply  some  of  the  missing  details  concerning  ii,e  semantics 
of  the  tois.  In  order  to  make  the  process  easier,  we  have  taken  some  liberties  with 
the  syntax  of  ALPHARD  and  its  forms  [Wulf,  1974]. 
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form  register  = 

(declare  r=  nteger; 
infix  + (register  a,b)  = return  a + b; 
infix.  “(register  a,b)  = return  a - d? 
rni.x  # (register  a,b)  = return  a * o; 
inf.x  v(reg.ster  a,b)  = return  aib; 
function  read  = return  r; 

write  (.nteger  vai)  = r«-val; 
CXCOr.L  read,  write} 


The  infix  declaration  is  used  to  define  binary  infix  operations  on  instances  of  the 
form.  Notice  tnat  there  is  nothing  in  this  definition  that  reveals  the  nature  of  the 
register  and  its  structure.  A more  realistic  definition  would  be  the  following: 


form  register(mteger  size)  = 

(Lucmre  r — 01 1 vector  (size  ) ; 
tunct.on  vaiue  = 


be;in  c jc.are  integer  sum; 

Sum  -* — r [ 1 J ; 

Inc r i from  2 Li  r.size  dfl  sum  ♦•sum  *2  +r[i ] ; 
return  sum ; 


eni; 

ir.f ix  t (register  a,b)  = return  a.value -t-b.value: 
iti'ix  -(register  a,b)  = return  a.value-b.value: 
infix  # (register  a,b)  = re1  urn  a.value *b.vaiue: 

■ nfix  t (register  a,b)  = return  a.value fb.value: 
function  read  = xiuni  r.value; 

dorr  i from  r.s.ze  Li  1 dQ.  begin  r[i]  <*val  mod  2 ; val  <-val 
t.xnort  +,  *,  t,  read,  write  }; 


2,  end; 


In  the  example  above,  the  register  is  defined  as  a vector  of  bits  and  the  vaiue  of 
the  register  is  encoded  using  the  two's  complement  representation.  The  function 
"value"  is  not  exported,  thus  the  real  nature  of  the  register  as  a bit  vector  is  hidden. 


The  read  and  write  functions  are  redefined  to  allow  the  transfer  of  vaijes  in  and  out  of 
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tne  register.  The  "dot"  notation  is  used  here  to  indicate  the  access  to  an  attribute  of  a 
register.  Thus  r.size  is  the  register  size,  as  specified  in  the  declaration. 


I'op  Level  Description.-  The  following  description  of  the  PDP-8  assumes  the  register 
and  memory  forms  defined  prevously.  For  the  cake  of  brevity  we  are  not  defining  the 
10 — I EXECUTE  and  OPR_EXECUTE  processes  evoked  by  the  EXECUTE  process. 


declare  memory  M(0:4096]; 
declare  register  AC<0: 1 1 >, 

IR  <0 : 1 1 > , 

PC  <0 : 1 1 > , 

L<>, 

LAC<0:12>:=LQAC, 

UATA_SWITCHES  ■ 0 : 1 1 >, 

STOP_SWITCH<>, 

CfviPA<0: 1 1 >, 

0P_C0Dc  :=IR<0:2>, 
pAGE_BIT:=IR<4>, 

INDIRECT BIT  :r|R<3>; 

INTERPRETER  :=  (IFETCH;next  DFETCHjnext  EXECUTE ;next  INTERPRETER) ; 
IFETCH:=  (IR  <r-M[PC]  ;PC  «-PC  + 1 ) ; 

□FETCH :=(COMPUTE_ADDRESS;next  DEFER ADDRESS); 

EXECUTE  :=( 

(0P_C0DE  = 'AND'  =>  AC  <- AC  aM(CPMA]  ) ; 

(OPCODE  -’TAD'  =i>  lAC  «-  LAC  + M(CPMA] ) ; 

(GP_CODE  = 'ISZ'=yM[CPMA]  *-to[CPrviA]  + 1 ;next 

(M[CPmA]<0=$PC*-PC  + 1)  ); 

(0P_C0DE  = ’DCA'  =}M[CPMA]  <-AC;AC<-0); 

(0P_C0DE  = '.  ,vlS’  =>M[CPMA]  <-PC;PC«-CPMA  + 1 ) ; 

(0P_C0DE  = ' JMP'  =>  PC  <-  CPMA ) ; 

(OP_CODE  = 'IO'  =»iO„EXECUTE) ; 

(0P_C0DE  = 'OPR'  =»  OPR_EXECUTE ) 

); 


COMPUTE^ ADDRESS  :=  ( 

(PAGE_BIT  = 1 =»CPMA  <-PAGE_NUMBERDPAGE_ADDRESS ) ; 
(PAGE_.BIT  = 0=>CPMA  «-0DPAGE_ ADDRESS) 
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); 


DEFER^ ADDRESS  :=  ( 

INDIRECT BIT  = 1 => 

(10iS<CPMA<17i8=>M[CPMA]  t-M[CPMA]  + l); 
next  C°MA*-M[CPMA] 

); 


Rodt' jinition  oj  the  memory  form.~  After  the  above  definition,  the  design  can  proceed 
in  several  d'reciions,  for  instance,  we  can  define  the  register  operations  in  terms  of 
bits,  we  can  denne  tne  interpretation  o.’  me  instruction  register,  or  we  can  define  the 
memory  operations  in  more  deta.I.  We  choose  the  latter,  at  least  because  it  will 
produce  a more  homogeneous  description  (i.e.,  the  operations  will  be  in  terms  of 
registers ). 

Defining  tne  memory  as  a vector  of  registers  requires  two  parameters,  the 
number  of  registers  (words)  and  the  length  of  each  register.  The  memory  in  the 
following  definition  requires  two  auxiliary  registers  to  perform  the  read  and  wnie 
operations.  These  registers  arc  not  exported  out  of  the  term,  i.e.,  they  are  local  to 
the  memory  module. 


torm  memory i'nioger  size  .wlengtn)  = 

{deciar.il  m = regisier(wlengin)  vector(size); 
mar  = register  (log2  (size )) ; 
mb r = register  (wiength) ; 
rccn-s  m( register  xj  = m[x.v3iue]; 
hmcuiiiil  read  (register  addr)  = 

bemn  mar^-addr;  mbr  <-m[mar] ; return  mbr;  end; 
Qmikm  write  (register  addr,val)  - 

beg.n  mar  *-addr ; mbr  "<-val ; m[rnar ] <-rnbr;  end; 
excort  road,  write  ) 


Soi..e  Aspects  of  the  Symbolic  Mampulat  on 
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The  access  declaration  ind,cares  that  the  vaiue  or  the  register  is  used  as  the 
index  in  tne  memory  vector.  The  effect  of  the  redefinition  of  the  memory  is  illustrated 
in  the  foi  owing  descript  on,  n which  the  read  and  write  operations  on  the  memory  have 
been  replaced  by  the  correspond  ng  sequences  giver  in  the  "^ne  description  of 

the  machine  itself  has  not  changed,  only  the  definition  of  one  of  its  components.  This 
aliov/s  us  to  redefine  the  memory  at  any  point  in  time  without  having  to  change  the 
description. 


doc!. ire  memory  M(0 :409o]  <0:11); 
d^r,,.re  register  AC <0 : 1 i > , 

1R  <0 : 1 1 > , 

PC<0: 1 1 >, 

L<>, 

LAC<0:12):=LUAC, 

DATA_SWITCH£S<0:11>, 

STOP_SWITCH<>, 

CMPA<0 : 1 1 > , 

OP__CQDE  :=  IR  <0 : 2 > , 

PAGE_BIT  :=iR<a)  , 

INDiRECT BIT  := iR  <3  > ; 

INTERPRETER :=(IFETCH;next  DFETCH;noxt  EXECUTEjnext  INTERPRETER); 


IFETCH:=  (mar  «-PC;noxt  rnbr  <-M[mar]  ;next  IR  <-rnbr  ;PC <-PC  + 1 ) ; 

DFETCH  :=  (COMPUTE_ADDRESS  ;next  DEFER_ADDRESS ) ; 

EXECUTE  :=( 

(OP_CODE  = 'AND'=>mar  <-CPMA;noxt  rnbr  <-M[mar]  ;next  AC<-ACnmbr); 
tOP_CODE  = 'TAD'  =)rnar  <-CPrv1A;next  rnbr  <-M[rnar  ] ;next  LAC  t-LAC  + mbr ) ; 
(OP_CODE  ='ISZ'=)mar  «-CPMA;noxi  mbr«-M[mar];next  mbr  «-mbr + 1 ;nex* 
M[mar]  <-mbr  ;next  (rnbr<0  =)PC <-PC  + 1 ) ); 
(0P_C0DE-'DCA'=)mar  <-CPMA;next  mbr  «-PC;next  M[mar]«-mbi  ; AC«-0); 
(0P_C0DE  = 'JMS'=)mar  <-CPMA;ncxt  mbr  <-PC;next 
tvi[rnar]  ♦-rnbr;  PC  <-CPMA  + 1 ) ; 

(OPJCODE  = 'JMP'=> PC  <-CPMA); 

(0P_C0DE-'I0'=)I0„EXECUTE); 

(OP_CODE  = ’0nR'  =)  GPR_EXECUTE ) 

); 
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t 


COUPUTE_ADDRES^U  ^cpma^PAGE_NUMBERDPAGEJIDDII£S5)! 
(PAGE_QiT  =0=>CPMA  «-0  OPAGE_ADDRESS ) 


DEFER_ADDRESS:=( 

(m8<CPVIA<  1718=>mar  «-CPMA;next  mbr  «-M[mar ] ;next 
rnbr  ♦-mar  + 1 ;raxt  M[mar]  «-mbr ) ;next 
mar  *-CPMA ;next  mbr  <-M[mar  ] ;next  CPMA*-mbr 


Redefinition  of  the  register  [null--  So  for  we  have  been  dealing  with  registers  as  it 
they  were  integers.  This  ,s  cmply  an  abstraction.  Hardware  registers  are  built  as 
array  of  bits  and  Ineretore  the  operations  must  be  ultimately  defined  m terms  ol  logic 
network  operating  on  individual  bus.  The  iflao  network  is  not  defined,  informally,  it 
represents  a set  of  wires  (memoryless  components)  used  to  carry  information  back  and 
forth  between  other  components.  The  following  definition  of  a register  indicates  how 

the  operations  could  be  performed: 


form  register  (integer  size)  = 

{ H «•» r I a r e r = bit  vector  (size  l ; 

press , rOntep.er  x>=  , , , 

hnTTin  Hhsr'.ciro  n = networkd  );  n[l]  «-r[x];  n;  end; 

access  r<intep,erpoir  x;  = , 

hp-7in  pnclnre  r,  = network(x.ub.va,ue -x.lb.s alue  + 1 ) , 

forrii  i inn  cm  n[i ] w[i +x.ib};  n 

end; 


/ 
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inf .x  + (register  a ,b ) = 

('r>r\-<rn  x = network (a.size  + 1 };  carry  = network(a.size  + 1 / ; 
carry  [carry.size]  *-Q; 
deer  i from  a. size  la  1 do. 
be&in 

x[i  + l]  <-a[i]  €>b[i  ] ©carry [i  + 1 ; , 

carry  [,]  «-a[i]  Ab[i]  va[i]  Acarry[i  + 1 ] vb[i]  Acarry[  + 1 ]; 


x [ 1 ] '"carry  [ 1 ] ; 
rotLr.Q  x; 

cod; 

infix  - (register  ,t,b)  = . . . . 

■ nf ix  + (register  a;  network  b)  = 

nng.n  ( _r_i  .r?  x ■ register  (O.size ) ; x^-b;  Lalau:  a + x;  end; 
itv'iv  t tnetw'ors  a;  register  b)  = . . . . 
infix  -r  (register  a;  integer  b)  = 


H •">  r I 


< - register (a.size);  x *- D;  nniiin  a + x;  mid; 


fane  inn.  read  = return  r; 
function,  wr.te (integer  va)  - 

L i from  r.size  In.  1 l2  ! 1 ? ■ n r[i ] *■ vai  mod  2;va  *"val  i 2 ; end; 

infix  write  (register  b)  = U . i £ b L2  r(i]  «-b[. } ; 

infix  write  (net  worn,  0 ) = t . . i mo  £2  r [i  ] »*b[i] ; 
export  i ,'ead,  write  } 


With  the  last  example  the  power  of  the  LQim  mechanism  is  mor  apparent.  We 
can  define  and  redefine  data  types  ana  operations  without  disturbing  the  rest  of  the 
description.  The  example  also  shows  a possible  way  of  implementing  the  adder.  If  the 
descr.ption  is  taking  literally,  it  implies  that  every  register  is  in  fact  a functional  unit, 
capable  of  performing  any  ontnmetic  operation.  For  a first  approximation  tms  may  be 
an  acceptable  definition.  A better  definition  would  aeciare  a single  functional  unit  and 
all  register  operations  couid  then  oe  defined  using  this  unit.  It  is  clear  also  that  we  can 
declare  other  types  of  registers,  for  instance,  counters  that  wouid  look  like  any  other 
register  but  with  the  property  that  some  simp  e operations  (e.g.,  add  1,  subtract  1,  set 
to  0,  etc)  wouid  be  performed  directly  in  the  register. 
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Signals  and  Control  Expressions.-  Let  us  assume  tnat  we  are  satisfied  with  Our 
previous  descriptor,  (it  is  by  no  means  complete,  but  for  the  sal-e  cf  brevity  ,et  us 
accept  it).  The  sequencing  of  operations  as  expressed  in  the  description  does  not 
indicate  how  the  control  passes  through  the  machine  description,  i.e.,  the  semantics  o> 
"next"  and  is  specified  only  to  the  pont  of  knowing  that  certain  actions  are 
performed  concurrently  or  that  some  actions  must  be  completed  before  others  can 
start. 


We  can  formalize  the  sequencing  of  the  operation  by  using  control  expressions, 
based  on  an  unoerlymg  finite  state  machine,  of  the  following  ty r e: 

pre -condiTon  : achon  | post -condition 

The  pre  — condition  represents  the  condition  that  must  be  rnet  before  the  action 
can  be  executed.  The  action  is  initiated  as  soon  as  the  pre -condition  is  satisfied.  The 
post  —condition  indicates  the  conditions  that  exist  upon  completion  of  tie  action.  The 
pre —condition  is  expressed  as  a conjunction  of  signals  and  boolean  expressions.  The 
evaluation  of  the  pre-condition  must  be  an  indivisible,  timeless  action.  The 
post —condition  is  expressed  in  terms  of  the  signal  operator,  >£).  The  operator 
generates  a signal  that  can  be  used  oy  the  pre —conditions.  The  signals  are  assumed  to 
be  unit  pulses,  therefore  they  exist  only  for  a brief  time,  enough  to  evaiu  ; the 
pre-conditions.  The  latching  operator  £ can  be  used  to  store  a signal  for  ,ater  use  in 
a pre -condition.  Latched  signals  will  obviously  exist  for  longer  periods  of  time  but 
they  will  dissapear  as  soon  as  they  are  used  i.e.,  as  soon  as  the  pre-condition  tnat 
contains  the  latched  signal  is  rnet.  There  is  a memory  device  associated  with  each 
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instance  of  the  # operator. 


Examples: 
si*.  • * 
s 1 a a — 1 s 


| Ms2) 

. | >6(52,53) 


si  as2:  • • • • 

£(sl)  a<£(s2):  . . • • 


Given  the  following  3MF  description  of  ,3P 
ISP  description  into  a set  of  control  expressions, 


, we  can 
according 


algorithmically  transform  the 
to  the  rules  given  later  on: 


v — /i ' nAi ]i  ••  ( <s-act.on;  ) 

<process>  <-oe  . I < t(0n>  n„t  <s-action> 

<o  - action  > ::=  <p-acl.on>  | se 

<p-act.on>  {J'/*  <s-Kt,on>  ) I 

<C"aC!'0n^co"aett^>  =»  <action-nst > ) 


ISP  to  Control  Expressions 

Translation  Rules.  - 
ore  -condition 

action 

post  -condition 

descripuon 

1)  label  :=  ( s -action  ) 

r 

label 

: s-action 

; at 

| xf)(label_d)ne) 
| £($.’) 

2)  Si  : 5 ft  l 

Si 

'•ft 

I MS'') 

ie(Si')A^(si") 

| >£>(Sj) 

3)  Si  : next  ft  1 >6(Sj) 

Si 

Si* 

: u 
: ft 

| ^>(Si') 
| >0(Sj) 

4)  Si  : ot=*ft  1 >6(Sj) 

Si  AcC 

: ft 

| >6(Sj) 
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Si  A ic i 

• 

I />(Sj) 

5)  Si  : decode  oc  =>/?0,  . 

fin  | £(Sj) 
Si  AoC  =0 

: fiO 

I >0(Sj ) 

• • • • 

Si  AoC  =r, 

: fin 

I £(Sj) 

6)  Si  : ( oi  ) 

1 £(Sj) 

Si 

: o < 

I £(Sj) 

7)  Si  : label  | 

MSI) 

s. 

Si  Alabel_done 

•• 

| >6(label) 
I >6(Sj) 

As  an  example,  we  wil  apply  the  above  rules  to  part  of  the  PDP8  description, 
specifically,  the  ISZ  instruction. 


1 ) Applying  rule  0 to  the  EXECUTE  process: 

EXECUTE  : . . . . I *>(EXECUTE_DONE) 

2)  Applying  rule  5 to  separate  the  individual  instructions: 


EXECUTE  a OP_CODE  = ’ISZ" 


| >£>(EXECUTE_DONE) 


3)  Applying  rule  3 several  times  to  the  s -action  describing  the  instruction: 


EXECUTE  a 3P_C0DE  = ’ISZ’ 

51 

52 

53 

54 


: mar  «-CPMA 
: rnbr  <-M[mar] 

: n br  «-rnbr  + i 

: K [rnar]  <-mbr 

: { mbr<0=»PC<-PC  + l ) 


| MSI) 

I )Z>(S2) 

I >£>(S3 ) 

| X)(S4) 

| >O(EXECUTE_D0NE ) 


4)  Applying  rule  4 to  the  last  component: 


EXECUTE  a OP_CODE  = 'ISZ' 

51 

52 

53 

54  Ambr<0 
S4a-(M8R<0) 


: mar  «-CPMA 
: rnbr  «-M[mar] 
: rnbr  *-mbr  + 1 
: M[mar]  *-mbr 
:PC«-PC  + i 


I MSI) 

I M S2) 

I MS 3) 

| >£>IS4) 

| >6(EXECUTE_D0NE) 
| £(EXECUTE_DONE) 
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The  complexity  of  the  actions  in  the  control  expressions  can  be  arbitrary.  This 
ailov/s  us  to  expand  the  description  in  selected  parts  cf  the  machine.  If  we  want  to  oe 
more  precise  about  the  timing  of  the  operations  we  can  add,  to  the  form  defining  the 
machine  component,  the  information  necessary  to  indicate  how  the  signals  are  produced. 
For  instance,  we  can  add  to  the  write  operation  in  some  register  form  the  statement 
"r.innai  after  200"  to  indicate  that  the  write  operation  takes  200  nanoseconds.  A 
synchronous  machine  could  be  specified  by  the  statement  "signal  OH  P3  where  P3  is 
the  nane  of  a dock  phase. 

Since  we  can  in  fact  represent  ail  the  operations  in  terms  of  register  transfer., 
with  the  appropriate  delays,  we  have  a convenient  mechanism  to  ind  cate  the  timing  in  a 
machine.  All  we  have  to  do  is  provide  the  appropriate  signal  OH  or  signal  allfiC. 
statements  in  the  write  function  of  the  forms  describing  each  component. 

At  this  point  a reshuffling  of  the  description  may  be  desired  to  simplify  the 
control  logic.  It  is  advantageous  to  group  the  primitive  operations  by  the 

pre  —conditions  under  which  they  are  triggered  rather  than  by  the  position  in  an 
opcode  sequence.  This  is  straightforward  and  easy  to  verify  the  correctness  of  the 
transformation.  A related  problem  is  the  reduction  of  the  number  of  control 

expressions  by  renaming  signals  that  are  produced  under  similar  circumstances  anu  with 
similar  effects.  The  importance  of  this  "optimization"  is  evident  since  the  number  of 
different  signals  is  related  to  the  number  ot  possible  states  of  the  machine,  part  of 
which  must  be  encoded  in  the  instruction  code. 
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CONCLUSIONS 


We  attempt  to  ease  the  task  of  programming  by  reiativizing  the  production  of 
software  to  the  machines  in  which  it  will  execute.  The  vehicle  is  a symbolic  description 
of  the  hardware  machine.  This  new  area  of  appicaiion  tor  computer  descriptive 
languages  reauires  some  properties  that  are  not  found  in  existing  notations.  The  use 
of  structured  programming  concepts  in  the  descrmtion  of  a computer  system  will  allow 
the  solution  of  a range  of  problems,  as  outlined  in  tins  paper,  by  manipulation  of  these 
symbolic  descriptions. 
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